Home

阅读提示：Databricks 的数据/AI 栈更新很快，本文所有组件都标注了可用性状态（GA = 已正式发布；Beta / Public Preview = 预览；Private Preview = 私有预览；Labs = Databricks Labs 社区项目，非官方 SLA）。凡标注 Preview / Beta / Labs 的组件，落地时都应准备兜底方案。状态以文末来源核实时点（约 2026-08）为准，正式立项前建议再核对一次官方文档。

---

1. 总览：模块 ↔︎ Databricks 落地件对照表

---

2. 逐模块落地件详解

2.1 模块① 动态信息输入

落地要点：

• 流式 vs 批式两条路径在 SDP 里统一表达：埋点/交易走 streaming table，周期汇总走 materialized view。
• 结构化数据直接落 Delta 表并在 Unity Catalog 打 tag；非结构化 Context（OKR、项目进度、竞品情报等）以文件 + 元数据入湖（SharePoint / Google Drive 等 GA Connector 可直连协作文档源），等待模块②做图化与嵌入。
• 外部实时检索（Genie Code Web Search）与托管入湖（Connect / Auto Loader）分工：前者补”此刻公开可见”的缺口，后者补”受治理、可溯源”的企业资产；Agent 消费时二者需打不同置信度标签。

2.2 模块② 知识与记忆

两类记忆的落地区分：

• 领域知识 / 规则（合规、SOP、指标口径）→ Metric Views + Unity Catalog 受治理对象，改动走审批。
• 经验记忆（案例、反馈样本）→ Vector Search 索引，由模块⑤自动回写。

复核策略落地：

• 用 OntoRank 权威分排序，高权威/高风险知识人工精审，其余 AI 预筛 + 抽样。

多部门 Context Namespace（域隔离）落地机制（Phase 1 即启用，不要等到多 Agent 再补）：

• 表：各部门结构化对象按 Unity Catalog catalog.schema 划界；行级敏感用 ABAC / Row Filter / Column Mask。
• 文件 / Volume：用 schema 权限隔离，而不是把行级过滤套到文件上。
• 向量：索引带 domain 等 metadata；检索默认加 Filter Expression（如 domain = 'supply_chain' OR domain = 'corporate'）。
• 指标：集团级 Metric Views 放公共 schema；部门口径放域 schema，跨域只暴露契约化只读视图。
• 跨域检索：编排层先做身份与授权（Gateway / UC 权限）；授权通过后，由 Agent 检索调用注入跨域 Filter 组合——Filter 在检索层，不在 Gateway 控制面「传入」。两域定义冲突时：集团公共定义优先，其次 OntoRank + 请求域优先级。

2.3 模块③ AI 处理逻辑

Genie 产品矩阵（命名对齐，避免混称）：

两个 AI 角色的落地：

• 监督者：SDP/Jobs 产出 output 与 sensor 指标 → MLflow Tracing + scorers 汇总、监控、发现异常。
• 决策顾问：基于 Genie Agents（over Metric Views）+ Ontology 上下文做 OKR loop review，产出建议。

“固化判据”怎么落地：

• 用 Unity AI Gateway 的 inference table + MLflow 分析某类 AI 问答的频率 × 稳定性 × 风险，达标者从”探索性用法”晋升（promote）为 Lakeflow Job。这道闸门是模块③的核心工艺。

能力契约（Capability Contract）生命周期：

2.4 模块④ 面向业务的执行策划

对内（送给员工/leader）：

对外（触达客户）：

• CustomerLake（Agentic CDP，Private Preview）：以 “infinity campaigns” 持续响应客户 context，把手动 trigger 的触达自动化。
• 兜底：在 CustomerLake 可用前，用自建激活 Job（Model Serving 输出 → 触达渠道）替代。

落地要点：

• 路由复用模块② Genie Ontology 的组织图，别重建；始终读最新组织结构防”送错人”。
• 执行分级（全自动 / 人工审核 / 仅建议）用 Agent Framework 的 human-in-the-loop / approval 机制实现；高风险（资金、对外承诺）默认人工确认。
• 每条建议附血缘：复用 Unity Catalog lineage，保证可解释、可核对。
• 通道优先序建议：能落表格 / Slack·Teams 的先走 Genie One 插件（摩擦力最低）→ 需审批下钻走 Apps → 需项目跟踪走 Meegle → 正式存档走邮件。
• 人员路由 vs 能力路由：找人复用 Ontology 组织图；找部门 Agent 走契约发现，二者不要写进同一张硬编码表。
• 动态发现（Agent Discovery，落地模式，产品名需立项前核对）：跨部门调度时不写死路由。推荐实现顺序：① 查 UC 中带 agent-capability 标签的 Functions / MCP 工具（当前最稳）；② 若已开通 Agent Services（Beta），再用其工具检索能力做意图匹配；③ Genie Agent / 相关 API 仅作辅助，不要写成 Unity AI Gateway 已 GA 的「Tool Search」API。发现失败则只送人、不自动调用对方 Agent。

2.5 模块⑤ 评估 / 反馈 / 学习

落地要点：

• 三类反馈 → 三层：业务数据（MLflow/Inference Tables）→ 策略层；员工任务反馈（Meegle 回执 + 文档）→ 知识/流程层；trace 监控（Lakehouse Monitoring + DABs）→ 基础设施层。
• 双重 CI/CD：模型/Agent 改动过 MLflow 评估门禁；SDP / Job 管道改动过 Pipeline 单元测试门禁，再经 DABs 发布。硬学习（改 Job / 管道）不得跳过测试绿通。
• 回滚判据：MLflow 监控发现漂移/劣化 → 经 DABs + Git 回退到上一个良好版本，回滚是一个动作而非事故。
• 解耦的异构评估（Domain Evaluation）：CLEARS 与域内 KPI 正交——前者是质量/安全/成本，后者是业务结果，不能互相替代。
• 部门局部评估：各部门基于 MLflow 3 Custom Judges 编写域内指标（如风控「拒贷误伤率」，营销「ROI 提升度」），在部门专属 DABs 管道中跑评估，驱动域内软/硬学习。
• 中央治理评估：Unity AI Gateway 统一在 Inference Tables 上挂载全局 CLEARS（尤其 Safety、Latency、Cost）与漂移告警，只拦截全局合规与模型风险。
• 归因纪律：对外触达用 holdout / A-B（CDP 通常原生支持受众 holdout），确保学到的是因果增量。
• 回写路径：软学习 → 更新 Vector Search 索引（经验记忆）；硬学习 → 经晋升判据 + 单元测试绿通改 Lakeflow Job / Agent 版本。

2.6 编排 / 治理层（神经中枢）

数据安全副产品正落在这一层：Unity Catalog 管权限、出口与 Secrets + Unity AI Gateway 管 AI 流量与托管工具，共同保证员工在”信息最小必要”下工作。联邦不改变这条原则：跨域只流出契约化结论，不默认打开对方原始 Context。

运行时三旋钮（不写容量公式，只锁定执行点）：

1. Model Serving / Agent 端点：一域一 endpoint（或一契约一 endpoint），设 provisioned concurrency 上限；禁止无上限共享端点。对内「仅建议」可 scale-to-zero；审批流与对外触达保留最小 provisioned，避免冷启动误事。跨域调用经 Gateway 按调用方身份限流。
2. Lakeflow Jobs / SDP：域级 Cluster Policy 或 Serverless 预算；硬学习发布不得挤占试点域生产队列。Pipeline 单元测试留在 CI，不占生产并发。
3. 检索与 SQL：Vector Search 与 DBSQL 仓库按域分队列/仓，避免全公司共一个 warehouse。Gateway 限流就是域配额的执行点，不另建限流服务。

---

3. 分阶段实施路径（爬 → 走 → 跑）

按”先地基、再知识、后单 Agent 闭环、最后多 Agent 扩展”推进，每阶段有明确产出与退出标准。

Phase 0 — 治理底座（地基）

• 目标：数据可信、可治理、可追溯；凭据与出口受控。
• 关键组件：Unity Catalog（权限/血缘/tag）+ UC Secrets（GA）、Lakeflow Connect + Auto Loader + SDP（入湖到 bronze/silver）、Unity AI Gateway 核心面就位（为后续 Agent 流量预留）。
• 产出：受治理的数据底座 + 全链路血缘 + 凭据入 UC 治理；书面锁定工作区切法 A（单 Workspace + 一域一 Catalog，见 §4 决策 7）。
• 退出标准：核心业务数据已入湖、有血缘、权限收敛（数据出口开始受控）；Agent 相关密钥不落本地/非治理配置；租户策略已记录（默认 A，升级 B 的触发条件写清）。

Phase 1 — 知识层（把数据变知识）

• 目标：可信知识 + 可检索 Context；域标签与 schema 隔离从第一天就有，避免 Phase 4 在脏索引上补隔离。
• 关键组件：Metric Views（集团公共 schema + 试点域 schema）、Vector Search（索引必带 domain metadata，默认 Filter）、Genie Ontology（权威分/组织图）；业务问答侧用 Genie Agents 验收。
• 产出：指标口径统一 + 企业 Context 可被 Agent 检索；至少一套 corporate + 一个业务 domain 的 Namespace 约定。
• 退出标准：关键指标有唯一定义；Genie Agents 能基于治理数据正确回答业务问题；本域检索不会命中无关部门文档。

Phase 2 — 首个 Agent 单元（窄场景 pilot）

• 目标：跑通一个高价值窄场景的领域 Agent（先只做”仅建议”档）。
• 关键组件：Mosaic AI Agent Framework / Agent Bricks（构建）、Managed MCP via Unity AI Gateway（受治理工具）、Model Serving（部署，带 concurrency 上限）、Unity AI Gateway（路由/限流/成本/trace）；试点部门将其公开能力按 §2.3 先注册进 UC（即使暂时只有本域调用）。
• 产出：一个能产出建议的领域 Agent（如”转化率异常归因与改进建议”）。
• 退出标准：Agent 在真实数据上稳定产出可用建议，全程 trace 可查；工具调用经 Gateway/MCP，无散接绕过；该 Agent 至少有一条带 Schema 的公开契约（可供后续被发现）；Serving 端点有上限且账单带 domain 标签。

Phase 3 — 闭合闭环（让它会学习）

• 目标：③→④→⑤ 闭环，Agent 能自我改进。
• 关键组件：MLflow 3（评估/监控：全局 CLEARS + 该域 Custom Judge）、Inference Tables、Lakehouse Monitoring、DABs + Git（CI/CD + 回滚）、Lakeflow Pipeline 单元测试（Beta）、holdout/A-B。
• 产出：反馈回写模块②③；晋升/回滚判据生效；硬学习改管道前强制单测绿通。
• 退出标准：至少一次”反馈 → 改进 → 效果验证（带 holdout）“完整闭环跑通；模型门禁与管道门禁均曾真实触发并放行/拦截过。

Phase 4 — 执行落地与多 Agent 扩展（联邦化演进）

• 目标：接通对内/对外执行，并以 Domain Federation 把已隔离的域连成网络——本阶段做发现与跨域调用，而不是从零补隔离。
• 关键组件：Databricks Apps + Alerts + Genie One Native Apps（对内）、CustomerLake（对外，Private Preview，带兜底）、UC 契约注册表 + 发现模式（§2.4）、分部门 MLflow Evaluators、域配额与 Gateway 限流。
• 产出：各部门拥有自治的 Context Namespace 与评估规则；跨部门协同通过 MCP/UC 契约动态完成；宏观层「多 Agent 网络」成形。
• 退出标准：至少 3 个独立部门的 Agent 在各自 Context 隔离下稳定运行，且能通过注册表发现机制成功完成至少一次跨部门能力调用与结果回流（发现失败有降级：只送人）；人为把试点域 QPS 打到配额后，其他域 Serving 仍可用（noisy-neighbor 验收）。仍停留在切法 A，除非已触发 §4 决策 7 的升级条件。

---

4. 关键落地决策与取舍

1. Agent Bricks vs Agent Framework vs Genie 家族：task-first、少运维的场景用 Agent Bricks；需要复杂自定义编排的用 Agent Framework（可挂 Claude Agent SDK 等 harness）；业务自然语言分析用 Genie Agents，办公内嵌协同用 Genie One，开发侧辅助用 Genie Code。四者可混用，勿把 Genie One 与 Agent Bricks 当成同一产品。
2. 工具接入统一走 Managed MCP（经 Unity AI Gateway）：把 UC Functions / Genie Agents / Vector Search / DBSQL 作为受治理工具暴露，避免 Agent 散接数据、绕过治理；权限、访问日志与成本计入 Gateway 控制面。
3. Preview / Beta 组件必设兜底：CustomerLake 仍为 Private Preview；Managed MCP ↔︎ Gateway 深度绑定、Pipeline 单元测试、Genie Code Web Search、部分 Connect 源与 Gateway 高级策略为 Beta——规划纳入，但关键路径准备降级方案（自建激活 Job、本地/CI 单测脚本、关闭 Web 检索通道等）。
4. 固化判据要有机制而非拍脑袋：用 Gateway inference table + MLflow 量化频率/稳定性/风险，作为 promote 到 Job 的客观闸门；Job/SDP 改动再过 Pipeline 单元测试门禁。
5. 治理先行：数据安全副产品依赖 Unity Catalog + UC Secrets + AI Gateway 先就位；治理不到位，“数据留云上、只让结论流出”就不成立。
6. 中央 vs 联邦：Secrets、Gateway 身份、出口、全局 Safety/CLEARS、共享 Metric Views 保持中央；Context 索引、部门口径、Custom Judges、域内 Job 下放到域。发现用 UC 标签注册表，不把未 GA 的 Gateway Tool Search 当关键路径。
7. 工作区切法（租户）：逻辑隔离永远用 Catalog；Workspace 只在算力/账单/合规需要时再拆。默认与升级条件如下。

升 B 时：同一 UC metastore + SCIM；域侧只放实现，公开契约仍在中心；DABs 用 gov / domain_x 两套 target，禁止每域一份互不兼容的 Bundle 结构。切 Workspace 不重做 Context Namespace。

---

5. 风险与依赖

• Private Preview 依赖：CustomerLake 的可用时点不完全可控 → 兜底方案必备。
• Beta 面扩大但仍需兜底：Unity AI Gateway 核心已 GA，但高级 Service Policies / Agent Services、Managed MCP 深度绑定、Pipeline 单元测试、Genie Code Web Search 等仍为 Beta，不可当作零风险生产依赖。
• 发现能力产品化程度：跨部门 Tool Search 若依赖 Agent Services（Beta）或自建注册表查询；立项前核对官方 API，失败路径是「只送人」。
• 契约蔓延与破坏性变更：部门私自改 Schema 会导致调用方静默出错 → 必须走 §2.3 版本与双跑。
• 跨域 Filter 过宽：授权一旦变成「全打开」，Namespace 形同虚设 → 跨域只加白名单 domain，并记录审计。
• noisy neighbor：共享 Serving / warehouse 无上限时，一域峰值拖死全家 → Phase 4 必须做配额打满演练；跨域调用禁止广播扇出。
• 过早切多 Workspace：在契约注册表未中心化前升 B/C，联邦会碎成 N 套发现 → 先 A + 配额，触发 §4 决策 7 再升。
• 自研集成成本：Lark / Meegle 集成需自建（开放平台 API / webhook / Lark CLI），排期要留出开发量；Genie One 原生办公插件可覆盖部分通道，减少自研面，但不能替代项目管理系统集成。
• 归因纪律要前置：holdout / A-B 必须在 Phase 3 设计阶段就规划，事后补做难度大。
• Labs 组件支持级别：Ontobricks 为 Databricks Labs 项目，无官方 SLA，关键路径上需评估替代或自建。
• 组件状态时效：本文状态以约 2026-08 核实时点为准，正式立项前请再核对官方文档最新可用性。

---

6. 理论映射：文章理念 ↔︎ Databricks 能力（含留白）

本节把《高维逻辑的拓扑连线与现实锚点》（企业级 Agent 的贝叶斯本质与工程治理）中的核心主张，对到具体 Databricks 能力，并诚实标出平台留白——即文章最锋利、但需要在推理层自建的部分。本节回答的不是”用什么搭”，而是”为什么这么治理”，为整套架构补上理论依据。

6.1 对照总表

6.2 最突出的一处：符号 × 联结的知识统一

文章第一节的核心区分——KG 三元组是维特根斯坦意义上的”原子事实图像”（离散/符号/确定），向量嵌入是”分布式语义相似度”（连续/联结/概率）——Databricks 恰好把两者做成互补的一等组件：

• Genie Ontology / OntoRank 提供权威的显式知识图谱（符号侧）。其”权威分”直接把文章第五节的”语义质量红线 / Gatekeeper Agent”变成平台原生的量化信号——它本就是给知识节点按权威性打分、决定”哪条定义可信”。
• AI Search 提供连续语义相似度（联结侧），原生支持 hybrid 检索（全文 + 向量 ANN 并行、RRF 融合）与 cross-encoder 重排，正对应文章的”混合检索 + 交叉熵重排提纯”。

也就是说，文章里”符号 vs 联结统一于 Context”的抽象，在 Databricks 有对应的一等组件，而非要自己拼装。这也正是本落地文档模块② 的理论落点。

6.3 平台硬约束：logit 级机制在托管 / 外部端点上不可实施

文章最锋利的两个主张——logit 级不确定性拦截与 Dirichlet / UQ 校准——在 Databricks 的实际端点上无法落地，原因是接口层面的硬约束，而非”没做”：

• 托管 Foundation Model API 与经 AI Gateway 调用的外部模型（Claude、GPT 等）只暴露输出 token 的 logprobs——即已采样 token 的对数概率，不是全词表的 pre-softmax logit 向量。文章要的”原始 logit 绝对强度、方差、epistemic 拆分”拿不到。
• 生成过程在服务端，调用方无法在”自回归首个 token 产生前”插入架构级硬拦截。
• Dirichlet 建模、ECE 校准、Credal Set 都需要改模型头或拿全量 logits，托管与外部端点都不开放这个层级。

唯一可能的路径是自托管开源权重模型（GPU + 自定义 pyfunc serving），此时你拥有 forward pass，可加 evidential/Dirichlet 头、算 epistemic uncertainty、在 emit 前硬拒绝。但代价是：放弃托管 FM API 的便利、自担模型运维与 UQ 研究工作，且对专有模型（Claude/GPT）完全不适用。对于本架构主要依赖托管 + 外部模型的现实，这两项应视为超出实施范围。

6.4 可落地的替代：用行为级手段逼近文章的”OOD 即沉默”意图

虽然 logit 级机制做不了，但文章的治理意图（分布外 / 不确定时硬拒绝、保持沉默）可以用端点确实提供的能力逼近——只是作用在输出级 / 行为级，而非模型内部表征：

• 检索置信度门控（最实用）：若 AI Search / Genie 召回的最高相似度低于阈值，直接判定”围栏外 = OOD”并硬拒绝。这不需要任何 logits，且直接对应文章”边界之外即不可言说”。
• 输出 logprobs 启发式：用已采样 token 的 logprobs 做序列级置信度估计，低置信触发复核 / 拒绝（粗粒度，但可用）。
• 语义熵 / 自一致性：对同一输入采样 N 次，测输出分歧度，近似 epistemic uncertainty——无需模型内部信息。
• 独立 OOD / 不确定性分类器：作为 Agent 前置路由步，判定是否放行。
• AI Gateway guardrails + CLEARS Safety：输出层最后一道拦截。

一句话：文章的 logit 级内核在 Databricks 端点上不可实施（除非自托管开源模型，成本高且不覆盖专有模型）；但其”OOD 即沉默”的治理意图，可用检索置信度门控 + 输出 logprobs + 语义熵在行为级实现。Databricks 提供的是产品级的”围栏与骨架”，模型内部的”概率驯服”要么自托管自建、要么退而用行为级代理。

---

附录：来源

以下关于 Databricks 产品与算法的说明基于公开文档与报道核实（组件状态复核时点约 2026-08）：

• Databricks Blog — Lakeflow: A new era of agentic data engineering — https://www.databricks.com/blog/lakeflow-new-era-agentic-data-engineering
• Databricks Docs — What is Lakeflow Spark Declarative Pipelines — https://docs.databricks.com/aws/en/ldp/concepts
• Databricks Docs — What is Auto Loader? — https://docs.databricks.com/aws/en/ingestion/cloud-object-storage/auto-loader/
• Databricks Blog — Agent Bricks: Data + AI Summit 2026 — https://www.databricks.com/blog/agent-bricks-dais-2026
• Databricks Product — Agent Bricks — https://www.databricks.com/product/artificial-intelligence/agent-bricks
• Databricks Docs — Evaluate and monitor AI agents (MLflow 3) — https://docs.databricks.com/aws/en/mlflow3/genai/eval-monitor/
• Databricks Blog — MLflow 3.0: Build, Evaluate, and Deploy Generative AI with Confidence — https://www.databricks.com/blog/mlflow-30-unified-ai-experimentation-observability-and-governance
• Databricks Docs — AI governance with Unity AI Gateway / AI Gateway-enabled inference tables — https://docs.databricks.com/aws/en/ai-gateway/
• ITdaily — Not pagerank, but ontorank: Databricks Genie Ontology — https://itdaily.com/blogs/cloud/databricks-genie-ontology/
• GitHub — databrickslabs/ontobricks — https://github.com/databrickslabs/ontobricks
• Databricks Blog — Introducing CustomerLake: The Agentic CDP embedded in Databricks — https://www.databricks.com/blog/introducing-customerlake-agentic-cdp
• Databricks Docs — AI Search retrieval quality guide（hybrid search & reranking） — https://docs.databricks.com/aws/en/vector-search/vector-search-retrieval-quality
• Databricks Docs — Structured outputs on Databricks（constrained decoding） — https://docs.databricks.com/aws/en/machine-learning/model-serving/structured-outputs
• Raphael Zhu — 高维逻辑的拓扑连线与现实锚点 — https://zhuzp98.github.io/files/AI%20Thoughts/Enterprise_AI_thoughts.html

v1.4 增量：版本号与概念架构对齐为 v1.4。内容：工作区切法 A/B/C（默认 A）；Serving / Jobs / 检索三旋钮；域预算标签与 noisy-neighbor 验收；Phase 0/2/4 门禁。

v1.2 增量：Domain Federation 落地闭环（契约生命周期、发现降调为 UC 注册表模式、Phase 1 即域隔离、编排层补注册表/跨域授权/域配额）；风险补契约蔓延与 Filter 过宽。

v1.1 增量同步说明（产品公告时点）：Unity AI Gateway 核心 GA（2026-08-04）；Managed MCP connectors 归入 Unity AI Gateway 控制面（Beta，2026-08-06）；Lakeflow Connect 的 SharePoint / Google Drive Connector GA，OpenAI / PagerDuty Connector Beta（2026-08）；UC Secrets GA；Genie Spaces 统一更名为 Genie Agents，并与 Genie One / Genie Code 形成矩阵；Lakeflow Pipeline 单元测试 Beta（2026-07）；Genie Code Web Search Beta（2026-08）；Genie One Excel / Google Sheets 原生插件发布（2026-08）。正式立项前请以官方文档为准复核。